Cloudflare One · ZTNA Demo Cheat Sheet (SHORT)

~17 min · Tight first-call version · Conversational

This is the trimmed version. Full cheat sheet is in ZTNA_Demo_CheatSheet_FULL_BACKUP.html for deeper dives. Six beats only: Overview → Live Tunnel HA → Logs → Access + Policies → Live Firewall → Close.
Legend: ▶ click / nav · 💬 spoken line · $ terminal · ⏸ pause · ➡ transition

Pre-demo setup checklist

📌 Notes from last call · read before the next one

Secure Access Corp · Paul Branson (CIO), Mayah Stadler (Director, HR & Employee Experience), Oscar. Their VPN is at capacity, daily drops, India devs hitting AWS East are suffering, contractors can't install agents. They asked for less dashboard, more story, and a broader platform view next time.

How they want the next call run

Open action items

Their specific pain points (use their words back to them)

0. Introduce Cloudflare + frame the architecture (~11 min, before the dashboard)

▶ cf-demo-app.dustinburke23nc.workers.dev/vpn-vs-zerotrust → open BEFORE you log into the dashboard. Page loads on Tab 1 ("Cloudflare platform & connectivity") by default.

The 5-beat flow for Section 0: (1) who Cloudflare is + why you can trust the network → (2) where Zero Trust fits vs the CDN side → (3) what's on the platform → (4) how people and servers connect → (5) the specific VPN-vs-ZT argument. Each beat earns its place. No tangents.
Beat 0a · ~2 min

Who Cloudflare is, and why you can trust this network

Do this Tab 1 is already open. Let the diagram sit on screen for two beats before you talk. The diagram IS the opener. Don't ramble through context first.
Say this · who we are

"Before I get into Zero Trust specifically, I want to show you what Cloudflare actually is as a company."

"Most folks only know us from one product or another, and we do a lot more than that now."

(point at the diagram)

"Look at the shape of this picture."

"On the left side are the people and devices you need to protect. Your employees, your contractors, the laptops they use, the offices they work from."

"On the right side is everything they're trying to reach. Your apps, your servers, your networks, your cloud."

"Everything in the middle is us. One network sitting in between, doing the work for both sides."

Say this · why you can trust the network

"And the reason this network is worth taking seriously."

"We've been doing this since 2009. We started by solving DDoS attacks at internet scale, and that's still the foundation everything else runs on top of."

"Today we sit in front of about 20 percent of all web traffic on the internet."

"Last quarter we mitigated a record-breaking DDoS attack at 31 terabits per second, and we did it using 6 percent of our total capacity."

(pause briefly, then bring it back to them)

"I mention that not to brag, but because that same network, that same capacity, is what your Zero Trust traffic is going to ride on."

"Security and performance aren't bolted on after the fact. They're built into the same plumbing."

Takeaway to leave in their head: 330 cities, one network, built for scale from day one. That's the platform Zero Trust is built on.

0b · Where Zero Trust fits vs the public-internet side

→ Click Tab 2: "CDN vs Zero Trust". Same page you're already on. Front-runs Oscar's question from last call so he doesn't have to ask it.

"Zoom into that network. It does two different jobs. One side guards your public website, the other guards your private stuff. Let me show you side by side."

→ Click Animate flow on the embedded page. Let it run for 10-15 seconds. Don't narrate over the animation, let them watch.

"On one side, we sit in front of your public website like a bouncer at the door. Anyone can show up, we filter the bad stuff out before it reaches your servers. On the other side, there's no public door at all. We verify identity first, then we let the right person through to the specific thing they need. What changes is who's allowed to show up at the door in the first place. Today we're on the second side."
The takeaway from this beat: same network, two different jobs. The one we're here to talk about is the side that doesn't have a public front door.

0c · What's actually on the platform

→ Switch back to Tab 1 of /vpn-vs-zerotrust. Point at the six boxes inside the orange Cloudflare bubble. Pick the three that match their environment. Walk those in plain English. Mention the others by name. Don't recite all six.

"Inside that middle box are six things we do, all running on the same network. Zero Trust is the one we're focused on today. It's how you control who gets in, from what device, to which app. The next one over replaces VPN and MPLS for connecting offices, data centers, and cloud regions. There's AI security for the new stuff like employees pasting secrets into ChatGPT or autonomous agents hitting your APIs. And there's a developer side too, if your team ever wants to extend any of this with code.

You don't need all six on day one. That's the point. They're already here when you do. Same network, same place to manage it, same logs. A contractor logging in from Singapore, a branch office in Atlanta, a developer pushing code, an AI agent calling an API. All through the same network. All getting the same rules. All in the same audit trail. Most vendors stitch that together from companies they bought. We built it on one stack from the start."

→ 60-second deeper walk on the three that connect to their pain. Mayah, Oscar, and Paul all asked for broader platform scope last call. This is the answer.

"Three of these connect directly to what you described to me.

AI security. Your team is already using ChatGPT and Copilot, whether you've sanctioned it or not. We see when an employee pastes a credit card, customer record, or source code into one of those tools, and we block it inline. Think of it like DLP, but for AI specifically.

Network-as-a-service, which we call Magic WAN. This is what replaces your VPN concentrator and your MPLS bill. Your offices and your AWS regions connect to our network with a tunnel or a direct link, and we move the traffic between them on our private backbone. The same fix we're proposing for your remote-user latency, applied to your office-to-cloud traffic.

Workers, the developer platform. If your team ever needs to run custom code at the edge, that's Workers. Code that runs in all 330 of our locations, automatically. You probably don't need it day one. But if a project ever calls for it, you're not building a new vendor relationship to get it."
The takeaway from this beat: You're not signing up for six products. You're signing up for one platform. You enable what you need, when you need it, from the same dashboard.

0d · How people and servers actually connect to it

→ Stay on Tab 1. Shift focus from the orange chip row at the top down to the three-column diagram. Wait a beat so they see the layout.

"Now the question I always get next is the same. 'OK so how do my people actually connect to all of that, and how do my apps and servers hook in on the other side?' Fair question. Three ways on each side. Let me walk you through them, because one or two will probably match exactly how your environment is laid out today."

⚡ USER SIDE · 3 ways your people get in

→ Click card U1 (Managed employee laptop).

"First one is your regular employee on a company laptop. The laptop's already managed by your IT team. We push a small piece of software onto it called WARP, the same way you push anything else to a company laptop. The user never has to touch it or even know it's there. Once it's installed, every request that laptop makes goes through the nearest Cloudflare data center first. That's where we check who the person is, whether the laptop is healthy, and whether they're allowed to reach whatever they're trying to reach. All of that happens automatically, in the background, fast enough that the user doesn't notice it."

→ Click card U2 (Contractor / BYOD). This is the answer to Mayah's contractor question. Land it hard.

"Second one is a contractor or anyone on a laptop you don't own. You can't push software onto their laptop. You don't have rights to. So you've got two choices. Either they install WARP themselves, voluntarily, if you want the same level of visibility you get on company devices. Or, and this is the part most customers love, they don't install anything at all. They just open a link in their browser and log in with whatever identity you allow. Google, Microsoft, GitHub, even a one-time code emailed to them. They're in. Nothing on their laptop, nothing for you to manage, no agent that breaks when their machine updates. And if you really want to lock it down, we can render the whole app in a browser running on our infrastructure, so they see and click on the app but nothing actually downloads to their machine."
Mayah "Our third-party consultants can't install our security client, and our current VPN forces us to."
This is exactly the scenario U2 was built for. Say it back to her in her own words: "You said your consultants can't install your VPN client. With this, they don't have to install anything. They open a URL, log in with their own Google or Microsoft account, they're in. Scoped to just the one app you allowed." If you want to put a bow on it, pair with Browser Isolation so nothing ever touches their machine.

→ The natural follow-up: "So how do we pick between WARP and browser-only for any given person?" Answer it now in one sentence, then have the three specifics ready in case they push for more.

"Here's the simple rule. WARP for people you control. Browser for everyone else.

Your own employees on company-issued laptops get WARP, because the laptop is yours to manage and WARP lets us check more, protect more, and cover more kinds of traffic. Contractors and BYOD get the browser path, because you can't put software on their machine and browser-only is genuinely good enough for most of what they need to do."

→ If they ask why WARP is worth it when you can install it. Three specifics, deliver one or two, not all three.

"There are three real differences when WARP is installed.

One. The internal URL doesn't exist on the public internet. With a browser-only setup, the URL hr.acme-internal.com has to be in public DNS so the browser can find it. Someone scanning the internet can see that hostname exists. With WARP installed, the URL is private. Public DNS returns nothing. The laptop running WARP is the only thing in the world that can resolve it. From everyone else's perspective the site just doesn't exist.

Two. It handles more than just web traffic. Browsers only do HTTP and HTTPS. With WARP we can also tunnel SSH, RDP, database connections, thick-client apps, anything. So your developer doing Git over SSH, your DBA connecting to Postgres, your admin RDPing into a Windows box, all of that works without exposing a single port to the internet.

Three. We can see whether the laptop itself is actually healthy. A browser can tell us what version of Chrome it is and roughly where it's coming from. That's about it. WARP runs on the laptop, so we can check whether the disk is encrypted, whether the firewall's on, whether your EDR like CrowdStrike or Defender is actually running, whether the device is enrolled in your MDM. That's the difference between trusting an identity and trusting the whole device."
The one-liner if the room is moving fast: "Browser is easy and good. WARP is harder to deploy and great. Use both, for different people."

→ Click card U3 (Branch office / site).

"Third one is a whole office or location. Retail store, regional office, manufacturing site, whatever. You don't want to walk into a warehouse and install software on fifty laptops, three printers, and a bunch of IoT devices. So we don't make you. You connect the office's network straight to Cloudflare from whatever router you already have at the door. Palo Alto, Fortinet, Cisco, whatever brand. Two endpoints, a shared password, fifteen minutes of work. Once that connection is up, every single device behind that router gets the same protection. Laptops, phones, printers, security cameras, point-of-sale terminals, all of it. This is also the conversation that ends your MPLS bill, if you're still paying for one."
The line worth landing on the user side: "Three different ways in, depending on who the person is and what kind of device they're on. But here's the part that matters. The same rules apply to all three. Your security team writes the policy one time, in one place, and it covers everyone."

⚡ SERVER SIDE · 3 ways your apps and servers hook in

Oscar "How do I actually onboard my own EC2 instances? And can I secure RDP and SSH servers?"
This is the unfinished business from last call. Paul's hard stop cut you off right when you were getting into this. Lead with these three stories this time, in this order. S1 answers the EC2 question directly. S2 covers RDP, SSH, databases, the long-lived TCP stuff. S3 is for if they ever want to connect a whole data center or AWS region.

→ Click card S1 (Single server or VM). Oscar's EC2 question. Direct hit.

"First one is one app, one server. Could be an internal HR portal running on a virtual machine. Could be a developer tool on a box in your data center. Could be anything. You install a tiny piece of software on that server called cloudflared. Three commands, takes about five minutes. That little piece of software calls out to Cloudflare and holds the connection open. Nothing ever comes in from the internet. No public IP address. No firewall hole to open. No port to forward. Your app becomes reachable through us, and only through us. From the outside, that server looks like it doesn't exist."

→ Click card S2 (Whole VPC or subnet). Oscar's RDP / SSH question lives here.

"Second one is for when you've got a whole bunch of servers and you don't want to install something on each one. Maybe you've got a VPC in AWS with twenty different servers in it. Databases, Windows machines people RDP into, internal tools, the works. Instead of installing the connector on every single box, you install one connector on one server, and you tell it 'I speak for this entire network.' Now every server behind it is reachable, without ever touching the others. This is also the move when you've got legacy systems you literally cannot modify. SAP, old line-of-business apps, things running on operating systems nobody wants to touch. They never know we're there. The connector handles it all."
Oscar "Can we secure RDP and SSH servers via Cloudflare?"
Yes, and this is the architecture for it. S2 covers it natively. Your line: "Your Windows boxes you RDP into, your Linux boxes you SSH into, your databases, all of them. One connector represents the whole network. We control access at the identity layer, not at the network layer. So instead of 'this user is on the VPN therefore can reach the whole subnet,' it's 'this user is authenticated for THIS server, on THIS port, for THIS time window.'" If they want to see it visually, pop open /browser-ssh-rdp in another tab. Animated browser-based SSH and RDP with a live audit log.

→ Click card S3 (Data center or cloud region).

"Third one is when you want to connect an entire data center or a whole cloud region. Same idea as the branch office on the user side, but this time it's your server side. Your network team brings up a tunnel from your data center's edge equipment straight to Cloudflare. For the really big stuff, we can do something even better. We can run a literal direct cable between your network and ours, bypassing the public internet entirely. That's available at AWS Direct Connect, Azure ExpressRoute, Google Partner Interconnect, and at the major data center exchanges like Equinix. The product that ties all of this together, branches, data centers, clouds, into one connected network, is called Magic WAN. It's how customers retire their MPLS and SD-WAN appliances and just use Cloudflare's network as their WAN."
The line worth landing on the server side: "Notice what's the same across all three of those. No public IP address sitting on the internet. No firewall hole. No open port. Every connection from your infrastructure goes outbound, to us. From an attacker's perspective, the front door doesn't exist."
"So that's how it all hooks together. Three ways your people get in, three ways your apps and servers connect to it, and one network in the middle doing the work for everyone. Now let me show you the specific argument for why Zero Trust beats VPN, which is what you came here to talk about."

0e · The architectural argument for Zero Trust over VPN

Mayah "Our VPN is at capacity. Bottlenecks. Daily connection drops. It's a real problem for employees AND consultants."
Don't sell them on the problem. They're already living it. Acknowledge it first, then point to the diagram you're about to walk: "That's the architecture you're stuck with right now, and I'm going to show you exactly why those bottlenecks and drops are a design problem, not a vendor problem. Then we'll look at what fixes it." When you get to the red center box, name it as the thing she's been dealing with. Make her nod.

→ Click Tab 3: "What VPN costs you". Point at the three columns.

"Three columns. Your people on the left. The stuff they need on the right. And in the middle is the box every single one of them has to go through to get there."

→ Point at the red center box.

"Here's the thing. That middle isn't one product. It's a VPN box, a firewall, a cert store, an MFA appliance. When you outgrow it, you're not replacing one thing. You're replacing all of it. Three to five years, same story, same downtime weekend."

→ Point at "Your Cloud" on the right.

"And this is the part that kinda gets forgotten. Your own cloud has to take the same detour. Your contractor's in Singapore. Your VPN's in Virginia. AWS has a region next door to that contractor. But the traffic still goes all the way to Virginia and back. You're paying AWS to ship your traffic out, then paying again to ship it back in. Same thing with M365, Salesforce. Not even your apps. Still going through your box."

→ Point at "The Pattern" callout.

"Half a second of waiting, every click. And that's not because anyone built it wrong. It's because everything funnels through one place. Security, performance, cost. All stuck behind the same bottleneck. Now you have to make it bigger to fix any one of them."

→ Click "What Cloudflare delivers". Pause.

"Same picture. Left side hasn't moved. Right side hasn't moved. Your apps didn't go anywhere. What's different is the middle."

→ Point at the orange center box.

"One thing that sets us apart. The middle isn't a box anymore. It's a network. 330+ cities. Your San Francisco employee hits San Francisco. Your Singapore contractor hits Singapore. Nobody travels back to a central office to get checked in."

→ Walk the 8 capabilities. Slow down here.

"And while they're sitting at that local PoP, eight security checks happen in one pass.

WARP Check. Is the device healthy.
Identity Check. Who are you, confirmed by your existing login. Okta, Entra, whatever you use.
Access Policy. What are you allowed to reach.
Gateway. Web filtering, bad sites get blocked.
DLP. Is sensitive data leaving.
CASB. What's happening inside their SaaS apps.
Email Security. Phishing caught before it lands.
Browser Isolation. Risky sites run in our cloud, never on the laptop.

None of those are separate products. Same network. Same rules. Same logs."
If their eyes glaze over: "Don't worry about the list. The point is your team isn't running five vendors and trying to keep their logs in sync."

→ Point at "The Flip" callout.

"Same Singapore contractor, same app, now about 200ms. Less than half. Same people, same apps. The middle just stopped slowing them down."
Paul "Our India developers connect to AWS East. The traffic still has to cross the globe. How does Cloudflare actually solve that?"
This is the question that pulled the rug out from under you last call. Don't dodge it. Be honest about the physics, then explain what we DO change. Say it directly: "You're right that the bits still have to cross the ocean. Mumbai to Virginia is about 180ms one way no matter who you use. We can't break the speed of light. What we change is what happens at every other hop. Instead of the public internet, the traffic rides our private backbone between PoPs. Instead of building and tearing down a connection every request, it's persistent. Instead of bouncing through a concentrator in Virginia, the security check happens at the PoP nearest your developer. The number we typically see is around 145 to 210ms versus 280 to 490ms. Not zero. Cut in half. Honest math."

Open the tab and walk it if Paul's there. If he isn't, skip this and just say the 145 vs 280 number.

→ Click "Do the math · Latency" tab if Paul is in the room. If the room is non-technical, skip the math and just deliver the punchline number.

"For the engineers. Here's the hop-by-hop. 490 vs 212.

We can't break physics. Mumbai to Virginia, the bits still have to make the trip. About 180ms is the speed of light. Nobody breaks that.

But we change how they make the trip:

  • Public internet → our private backbone. Rush-hour streets to a toll road.
  • Connection stays open instead of being rebuilt every time. No setup tax per request.
  • Same data requested twice? Cached in Mumbai. Second user never crosses the ocean.

That's the 278ms, per click. Across a workday, real time back."
"Now that we've framed the architecture, let me show you what it actually looks like in the dashboard."

➡ Switch tab to one.dash.cloudflare.com. Last call feedback: don't sit in the dashboard for long. They want story over feature-diving. Keep this beat tight, get to the live tunnel demo (Section 3) faster than feels natural.

1. Opening / Cloudflare One Overview (~2 min)

▶ one.dash.cloudflare.com → Overview (landing page)

"This is the Cloudflare One Overview. The page you land on when you log in. It's designed to answer one question in 10 seconds: is my Zero Trust deployment healthy and being used, or is it just sitting there? Let me walk you through it."

→ Point at the counters at the top

"I just want to touch on a few items on this page. I won't go over all of them, some are self-explanatory. Start at the top. These counters are the pulse check. Users: 7 of 10 seats in use, that tells me adoption. Active devices, Targets, Applications. And Active Tunnels, which are outbound connections from my infrastructure to Cloudflare. I'll show those working live in a few minutes."

→ Scroll to "Your deployment" flow diagram

"This part is brand new, and honestly it's one of my favorite things on the platform right now. It's a flow diagram of how traffic actually moves through Zero Trust. Users on the left, policies in the middle, applications on the right. Toggle between Access Control mode (who's authorized) and Traffic Flow mode (what's actually moving). Every access request is a line you can trace from person to policy to application. No more stitching logs together to figure out who hit what."
"Notice the framing. Every metric is about users and applications, not networks. Zero Trust starts from identity, not subnet."

➡ Now let me show you the part most customers care about. Visibility.

2. Logs · Where the Proof Lives (~2 min)

▶ Insights → Logs

"Dashboards show trends. Logs show proof. Organized by control plane, so instead of one giant fire-hose, it's broken out by what enforced the decision."
"Takeaway: visibility. Who accessed what, when, why, all in one place. No stitching VPN logs, firewall logs, and app logs together at 2 a.m. If somebody asks 'what was Mayah doing yesterday at 3pm?', that's three filters away."

➡ Visibility is the foundation. Now let me show you the part underneath. How the connection itself works.

3. Connectors + LIVE TUNNEL DEMO (~5 min, the centerpiece)

▶ Networks → Connectors

"Cloudflare Tunnels are outbound-only connections from your environment up to Cloudflare. No open ports. No exposed IPs. The app connects out. Nothing listens inbound."

"I'm running two connectors here, not one. In production, you never run a single tunnel for an app you care about. Primary plus at least one replica. Same tunnel, multiple connectors. If one dies, the other keeps serving." 
$ syscloud

UNIT LOAD ACTIVE SUB DESCRIPTION
cloudflared.service loaded active running cloudflared
cloudflared-replica.service loaded active running cloudflared-replica
2 loaded units listed.
"Two scenarios. First, one connector dies. Then, both die. Two very different stories."

DEMO A · High Availability (one connector dies, traffic keeps flowing)

▶ On the EVE-NG server:

$ systemctl stop cloudflared
"Killing the primary only. In a real outage this could be a host crash, a network blip, anything that takes one connector offline."

▶ Switch to Safari → https://eve-ng.tarheel.us

"The app loads. From the user's perspective, nothing happened. This is the boring part of HA, and that's exactly the win."

▶ Back to dashboard → Networks → Connectors

"One connector degraded, one healthy. Cloudflare routes through the healthy one. No human intervention. No 3 a.m. phone call."

DEMO B · Full Failure (both connectors die, fail-closed)

▶ On the EVE-NG server:

$ stopcloud
"Now killing the replica too. Both down. Tunnel has zero connectors registered."

▶ Switch to Safari → https://eve-ng.tarheel.us

"Error 1033, Cloudflare Tunnel error. The tunnel is outbound-only, so when every connector drops, access fails closed. Nothing is exposed. The app is just gone from the internet's perspective. It stops AT Cloudflare, not at your tunnel endpoint."

"When a VPN concentrator fails, you usually have a hardware backup, a public IP somewhere, some path back to the network. And that path is the attack surface. Here, when the connectors go down, there's no path at all. Nothing to find. Nothing to attack."

DEMO C · Recovery (both connectors back, traffic restored)

▶ On the EVE-NG server:

$ startcloud

⏸ Wait ~5 seconds, return to dashboard

▶ Dashboard → Networks → Connectors

"Tunnel healthy. Both connectors connected. No firewall changes. No inbound ports. No VPN. That's Zero Trust in practice. Outbound-only, identity-first, automatic high availability."
THE ARCHITECTURAL POINT

One down → user sees nothing. HA does its job invisibly.
All down → app vanishes from the internet. Nothing to attack.
Back up → connectors phone home, access restored. No firewall rule changed.

"This is what 'fail closed' actually means."

📦 Onboarding internal servers (EC2, on-prem, anywhere) (~2 min, show if asked)

Customer trigger: "OK that's your lab, how would I actually onboard my own EC2 instances?" This is the answer.

▶ Networks → Tunnels → "Create a tunnel" (walk through, don't actually create)

"Three ways to bring internal servers into Zero Trust, depending on what fits your environment. Let me walk through them."

Option 1: Install cloudflared on the instance itself

"The most common pattern. Install our tunnel daemon directly on the EC2 box. Outbound-only port 443 to Cloudflare. That's the only network change needed. No security group changes. No public IP. No load balancer." 
# On any EC2 instance with internet egress:
curl -L --output cloudflared.deb \\
 https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb
sudo dpkg -i cloudflared.deb
sudo cloudflared service install <your-tunnel-token>
"Run those three commands, the instance shows up in the dashboard as a connected tunnel. Per-instance control, which is what I'm running on my lab right now."

Option 2: One Mesh node per VPC (subnet routing)

"What if you don't want to install software on every box? Run one Mesh node per VPC, point it at the VPC's address range, say 10.0.0.0/16. Now every server, database, and resource in that VPC is reachable through that single node, with nothing installed on the rest. Great for RDP, databases, file shares, anything you can't put cloudflared on directly." 
# On one EC2 instance acting as the subnet router:
sudo apt install cloudflare-warp
sudo warp-cli connector new <token>
# In the dashboard: Networks → Mesh → Advertise routes → 10.0.0.0/16
"One install, whole VPC reachable. For HA, run two Mesh nodes in different AZs. Same active-passive replica pattern you saw with cloudflared."

Option 3: Magic WAN (network-level integration)

"For larger deployments who want full SD-WAN, connect your VPC to Cloudflare over IPsec or GRE. No agents anywhere. The network itself is on Cloudflare. Bigger commitment, but it's how you'd connect data centers and large enterprise environments."
The honest framing: "Start with Option 1 for the first few apps. Move to Option 2 when you want to onboard whole subnets without touching every box. Option 3 is the long-game answer for large environments."

▶ Access Controls → Applications

"You just saw the eve-ng app working live. This is where I told Cloudflare it exists, and what rules users have to pass to reach it."

"Every request is evaluated in real time. Identity checked, policy enforced, before traffic ever hits the app."

"This is where it breaks from the VPN model. No 'once you're in, you're trusted.' Access is per-request, scoped to the application. You get this app. That's it. No free roam on the subnet."

▶ Access Controls → Policies

"Apps define what. Policies define who, and under what conditions. Define a policy once, reuse it across apps. The moment a user stops meeting policy, access stops. Not at the next login. Right then."
Paul "Our VPN already restricts access by role. What's actually different here?"
The honest answer is not 'we do it better.' It's 'we do it at a different layer.' Try this: "Role-based ACLs on a VPN are real, but they're network rules. 'Once you're on the VPN, you can reach the finance subnet.' The problem is two things. One, ACLs drift. Someone gets added to a group, never gets removed, six months later they still have access to something they shouldn't. Two, ACLs are coarse. They're 'can this person reach this network range,' not 'can this person reach this specific app, from this specific device, at this specific time, with this specific posture.' With us, every application is its own boundary. Every request gets checked. The drift problem doesn't go away because humans still manage groups, but the blast radius of any drift is one app instead of one subnet."

Then show him: click into a policy in the dashboard, point at the device posture and identity conditions. Make the abstraction concrete.

⚙ LAB NOTE · Context switch (just for me)

My Linux box runs both cloudflared AND WARP. They can't both be on. Tunnels are up, WARP is off right now. For the SWG section coming up, I need WARP on, tunnels off. 

$ stopcloud
$ warp-cli connect

Smooth transition line: "Alright, quick gear shift. We've covered how users get in. Now what happens to their traffic on the way out."

5. Firewall Policies · Live Traffic Demo (~4 min, the second wow)

▶ Traffic Policies → Firewall Policies → click the HTTP tab. Last call reminder: this is where it's easiest to slip into feature-spam. Stay on the "what" and "why" before showing the live traffic. Mayah and Oscar specifically asked for that framing.

"I'm clicking the HTTP tab. That's where the Secure Web Gateway demo lives. Real guardrails. Look at the Action column. Not just block or allow. Block social media outright. Redirect LinkedIn to a Cloudflare-approved page. Isolate Netflix in a remote browser so users can still watch but nothing executes locally. Same policies remote or in-office."

LIVE · Watch every policy fire in real time

▶ Switch to the Linux terminal · run: traffic-gen

"This script hits a list of sites through Gateway. Watch the color-coded output."
"GREEN · ALLOWED. Clean traffic, no policy matched.
"RED · BLOCKED. TikTok, Facebook, X. User sees a clean block page.
"BLUE · REDIRECTED. LinkedIn, YouTube → cloudflare.com.
"PURPLE · ISOLATED. Netflix, Spotify open in a remote browser. Pixel streams only.

"Same script, same network, four outcomes. Decided at the edge in milliseconds."

▶ Switch to Firefox · visit netflix.com directly

"Isolation in action. Netflix loads inside Cloudflare's remote browser. Small banner at the top, otherwise identical UX. Any script, any download, any exploit runs in our cloud. Not on the laptop."

▶ Pivot to dashboard · Insights → Logs → Gateway → HTTP · filter by tiktok.com

"Every decision logged. Filter by domain, see which policy fired and why. DNS layer underneath catches the broad stuff: malware, phishing, C2. HTTP handles the surgical stuff. Layered defense, one dashboard."

6. Closing (~1 min)

"What you saw today isn't a pile of security tools. It's a different access model."

"We didn't put users on a network. We didn't open ports. We didn't trust anything by default. Every access decision was identity, device, and policy, enforced at the edge. Tunnel up, access worked. Tunnel down, everything stopped. Nothing else was exposed."

"That's Zero Trust in practice. The real question isn't 'can you replace a VPN?' It's 'does your access model actually match how your business operates today?'"

⏸ Pause. Let it land.

"One more thing on lead times. Cloudflare has no lead times. No hardware to install. Sign up today, start working today. The environment you just saw, private app, registered domain, connected to my server, accessible from anywhere on the internet, took 20 minutes. Start to finish."

"Thank you for the time. Happy to take a couple of questions."

Q&A · back-pocket answers

For full Q&A coverage open ZTNA_Demo_CheatSheet_FULL_BACKUP.html. Top 5 most-asked here.

Reminder from last call: Paul, Mayah, and Oscar all said it's fine to say "I don't know, let me get back to you." Don't improvise. If a question goes outside what's in this cheat sheet, write it down and follow up. They respect honesty more than they respect a fast answer.

Zero Trust vs. VPN

VPNs put users on a network. Zero Trust gives access only to specific apps. With Zero Trust there's no lateral movement, no blast radius from stolen credentials, and no inbound firewall changes.

📊 Show them the visual: The Case for Zero Trust · visual comparison

Contractors & Third-Party Access

How do contractors get in without a VPN? Access. Log in with their own identity (Google, GitHub, email OTP), scoped to specific apps. No agent install for web apps.

Time-limited access? Set an expiration on the policy. Auto-revokes at the date you set.

Unmanaged contractor laptops? Route them through Browser Isolation. Nothing executes on their device.

Hostile or compromised? Remove from Access group. Session terminated. No cached VPN creds.

📊 Show them the visual: Contractor onboarding flow · Phishing defense (Browser Isolation in action)

Bottlenecks today vs. with Cloudflare

When they say something on the left, you say something on the right. Plain English, no jargon. Read it the way you'd say it to a friend.

If they say... You say...
"VPN's a nightmare on Monday morning. Everyone's signing in at once and it just crawls." "That's because everybody's traffic has to squeeze through one box, and on Monday morning that box can't keep up. We don't have that box. Your people connect to the nearest of our 330 locations around the world, so the load never piles up in one place."
"Our branch offices complain that everything routes through HQ before it gets anywhere." "Right, that's the detour problem. Their traffic goes to HQ, then back out to wherever it's actually going. Twice the distance. With us, the branch connects to the nearest Cloudflare location directly. The detour goes away."
"Our security setup is a stack of different boxes that all have to inspect the traffic in turn." "Yep, and each one adds delay. The traffic gets handed off five or six times before it ever reaches the app. With us, all those checks happen at the same place, at the same time, in one pass. Faster, and one bill instead of five."
"Our apps are in the US but our users are everywhere." "That's the global team problem. The bits still have to cross the ocean, we can't change physics. But instead of taking whatever messy route the public internet picks, your traffic rides our private network between cities. Think highway versus surface streets. Same destination, half the delay."
"Works fine in the office, but it's slow when people work from home." "That's the path from their home internet to wherever the app lives. Sometimes one section of the route is congested or bad. We watch every route in real time and steer the traffic around the slow parts. It's like Waze for your data, automatic, you don't have to do anything."
"Cloud storage bills are killing us. Uploads and downloads are slow too." "You're paying twice. Once to store the data, and again every time someone reads it. Our storage product has zero charges for reading your data, ever. And because we have a location near every user, uploads and downloads hit the closest spot first instead of going across the country."

📊 Show them the visual: VPN vs Zero Trust diagram covers most of these. Open the "Do the math · Latency" tab for the Mumbai-to-Virginia version.

Cloudflare Tunnel

What is it? Outbound-only connection from private apps to Cloudflare. No inbound firewall rules. No exposed IPs.

What if it goes down? Access stops. Nothing exposed. (You demoed this live.)

Cloudflare One Client (WARP)

Is it a VPN? No. Doesn't place users on a network. Traffic is policy-checked at the edge, not tunneled to a LAN.

What does it protect? Internal apps, SaaS, internet traffic.

🔨 "Isn't this just another VPN client to install?" · DROP THE HAMMER
Open with this. Slow it down, look them in the eye:
"Same form factor. Completely different architecture.
The right question isn't 'is this another VPN client?'
it's 'what do I get to uninstall when I deploy this?'"

Then back it up with these three counters. Fast, one at a time:

Counter 1
Often no client at all
 Most internal apps are web apps. Users just hit a URL, auth via IdP, they're in. VPN clients are mandatory. Ours are optional for web.
Counter 2
One replaces many
 Our client typically replaces: VPN client + SWG agent + DNS filter + sometimes CASB. The endpoint gets simpler, not more crowded.
Counter 3
Users feel faster, not slower
 Traffic routes to the nearest of 330+ edges, not a concentrator in HQ. We resolve DNS faster than most ISPs. Users tell us the internet feels faster after install.

⚡ The kill shot. Say this AFTER the three counters.

"VPN clients install software so you can pretend you're inside a network. Our client installs software so you can stop pretending. That's not the same thing wearing different paint."
Delivery note: Don't rush. Pause after the opener. Pause after each counter. Pause before the kill shot. Confidence = silence. If they push back after this, you've already won. They're negotiating, not rejecting.

📋 Follow-up answers · questions from the call

Plain-English answers you can deliver naturally. No memorization needed. Read it once, then say it your way.

1. (Oscar) What's the difference between Cloudflare's CDN/DNS stuff and Zero Trust?
🎬
Open this in a new tab while you answer
→ cf-demo-app.dustinburke23nc.workers.dev/cdn-vs-zerotrust
Animated comparison · public CDN/DNS pipeline vs Zero Trust pipeline · side-by-side view

Same network, different jobs.

Our CDN and DNS sit in front of your public website, like a bouncer at the door. Anyone on the internet can show up, and we filter the bad stuff out before it reaches your servers.

Zero Trust is for everything that isn't public. Your internal apps, your databases, your developer tools. There's no door for the internet to knock on. Users get verified by identity, then we let them in to the specific thing they need.

Example: your marketing site uses our CDN. Your internal HR portal uses Zero Trust. Same Cloudflare account, same dashboard, totally different traffic patterns.

2. (Oscar) Can we use Cloudflare for RDP and SSH to internal servers?
🎬
Open this in a new tab while you answer
→ cf-demo-app.dustinburke23nc.workers.dev/browser-ssh-rdp
Animated SSH terminal + Windows RDP desktop · live audit log · policy enforcement

Yes, two ways.

The easy way: users open a URL in their browser, log in, and get a working RDP or SSH session right there in the browser tab. No PuTTY, no Remote Desktop client, no agent install. Works from any laptop.

The power-user way: if your developers want to use their normal SSH client, they can. Cloudflare just makes sure the connection goes through identity and policy checks first.

Example: a contractor needs RDP into a production Windows box. You send them a URL. They log in with their Google account. They're in. You see every keystroke logged. When the project ends, the URL stops working.

3. (Paul) India developer to AWS East. Doesn't the traffic still cross the globe?

Honest answer: yes. We can't break physics. If the server is in Virginia and the user is in Mumbai, the bits still have to go between them.

But we change how they make the trip:

Example: a Mumbai developer pulling logs from an AWS East server. On a normal VPN that's about 280ms per request. Through us, it's around 145ms. Not zero, but cut in half.

If they push back: "Let's run a real test on your traffic for a week. I'll show you the actual numbers, not my marketing numbers."

📊 Visual: VPN vs Zero Trust diagram → click "Do the math · Latency" tab for the hop-by-hop breakdown.

4. (Oscar) How do I get my EC2 instances onto the Cloudflare network?

Three ways, depending on how much you want to install where.

The important part: in all three patterns, your servers only make outgoing connections to us. You don't open any firewall ports for the internet to reach them. There's nothing exposed.

📊 Visual: Onboarding internal servers · three patterns, animated diagrams

5. What about contractors who can't install our security client?

They don't have to. That's actually our strongest story for external users.

You send them a URL. They open it in any browser. They sign in with their own Google or Microsoft account, whatever they already have. They're in. Scoped to just the app you allowed.

You can set the access to expire automatically when the project ends. No tickets to clean up. No forgotten accounts sitting in your AD.

Example: you bring in three contractors for a Q4 audit. You give them a URL and assign them to the "Q4 audit" group. They use their own laptops. When December 31 hits, the URL stops working for everyone in that group. Done.

📊 Visual: Contractor onboarding flow · split-screen, animated

6. Are you really faster than our VPN?

For most users, yes. Usually noticeably faster.

A traditional VPN sends every user's traffic to one or two appliances at your headquarters. If you're a developer in London accessing an app in London, your traffic goes London → Texas → London → Texas. That's the speed problem.

We have data centers in 330+ cities. The user connects to the one closest to them. Policy gets enforced right there. Then traffic takes the shortest path to the app. No detour through your HQ.

Example: a sales rep in Singapore opens your internal CRM. On the VPN, that's a 300ms round trip through your US data center. Through us, it's 90ms because we enforce in Singapore. They feel the difference immediately.

How big the win is depends on how spread out your team is. If everyone's in one office, we're only a little faster. If you have a hybrid workforce across multiple continents, we're a lot faster.

📊 Visual: VPN vs Zero Trust · Global network map (330+ cities)

7. Can we see this with diagrams instead of dashboard demos?

Yes. I built a set of visual diagrams specifically for this. Click any of them:

For a 12-minute guided architecture walkthrough that hits multiple: Guided demo flow

For static slides: screenshot each demo, drop into a 3-slide deck, send as a follow-up.

8. How exactly does Magic WAN connect? What's the link?

Magic WAN hooks your network to Cloudflare at the router level, no software on any laptop or server. Four ways to make the connection:

What you get once connected: Cloudflare becomes both your network's on-ramp to the internet (Gateway, DLP, filtering) and the path between your sites. Branch-to-branch traffic flows through Cloudflare's backbone instead of MPLS.

Example: you have an AWS VPC in us-east-1, an office in Atlanta, and a data center in Dallas. Set up one IPsec tunnel from each, three tunnels total. Now anything in any of those three places can reach anything in the other two, securely. You retire MPLS. You retire the VPN concentrator. Network team configures it all in our dashboard.

When to use Magic WAN vs. Tunnel/Mesh:

📊 Visual: Onboarding flows. Magic WAN tab shows all four connection methods.